This disclosure relates in general to data processing, and more specifically, to emulation of a target hardware system.
A well known technique for developing a target hardware system and/or modeling its behavior is to emulate the target hardware system through the execution of software on a host hardware platform. Conventional emulation techniques require the full emulation of each hardware component in the target hardware system. Because conventional emulation techniques require execution of both the full software stack and an emulated hardware stack below it, each emulated component necessarily consumes more raw processing power than its physical counterpart. Consequently, emulation of a target hardware systems of significant scale (i.e., those with multiple intelligent hardware components managed by one or more management components) can be impractical on many host hardware platforms due to processing resource constraints.
Further, in even cases in which sufficient processing resources are available to perform a full emulation of each hardware component of the target hardware system, in many cases, emulation code that mimics the internal operation of each hardware component may not be readily available or easily developed. The present disclosure appreciates, however, that even in cases in which the internal operation of a hardware component is difficult to model, interfaces to the hardware components are frequently visible and well defined.
For emulation to be helpful, the emulator should be able to quickly and consistently produce a known state of the target hardware system. With conventional emulation techniques, replication of a known state in the emulator may entail creating an extensive litany of internal operations and/or user inputs performed on the target hardware system to achieve the known state. For so-called “corner” cases, a known state (e.g., a particular failure state) may only be reached after months of compounding problems or human actions in the target hardware system, which may provide insufficient logging to recreate the known state in the emulator.
The present disclosure further appreciates that it would be desirable for a user of the emulator should be able to introduce faults, change behaviors, or modify both software and hardware components in a way that does not require disruption of the emulation. In the case of emulated hardware components without a user interface, modification of the behavior of the emulator components may not be possible using conventional emulation techniques. For emulated hardware components that support user-level interaction, conventional emulation techniques only permit the emulated hardware component to be configured through the user interface, which artificially limits flexibility because user interfaces are typically designed to restrict the user from performing certain operations (e.g., invalid operations) in order to minimize errors.